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ABSTRACT: This paper builds on a technical report written by Carl Hewitt and 
Henry Baker called "Actors and Continuous Functionals". What is called a 
"goal -oriented activity" in that paper will be referred to in this paper as 
a "transaction". The word "transaction" brings to mind an object closer in 
function to what we wish to present than does the word "activity". This 
memo, therefore, presents the definitions of a reply and a transaction as 
given in Hewitt and Baker's paper and points out some discrepancies in their 
definitions. That is, that the properties of transactions and replies as 
they were defined did not correspond with our intuitions, and thus the 
definitions should be changed. The issues of what should constitute a 
transaction are discussed, and a new definition is presented which eliminates 
the discrepancies caused by the original definitions. Some properties of 
the newly defined transactions are discussed, and it is shown that the results 
of Hewitt and Baker's paper still hold given the new definitions. 

This report describes research done at the Artificial Intelligence Laboratory 
of the Massachusetts Institute of Technology. Support for this research was 
provided in part by the Office of Naval Research of the Department of Defense 
under Contract N00014-75-C-0522. 
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I. iiHrociiii t ion 

A transaction corresponds to our usual notion of a suhcomputation needed for 
subrou.tinev. It includes those events which occur because a certain request is made, up to 
and including the resultant reply. The notion of a request, followed by steps leading to a 
reply, appears over and over again in many different kinds of programming applications. 
Recursive function invocation, data bases, and interactive systems, for example, each 
illustrate the need for the concept of a transaction. In. recursive function invocation a 
request is made for I he value of some expression, and a reply is subsequently returned. 
When working v'ilh data ba^es, one often wishes to retrieve a piece of information and 
thus will submit a request. Here again, the activity involved in replying to that request 
constitutes a transaction. Interactive systems are really nothing more than a series of 
requests and replies, lisp, for example, uses the classic "read-eval-pr'mt" loop. 

The concept of a transaction is therefore an important one, and is extremely 
useful in reasoning about sequential program semantics. We need to establish a robust 
definition of a transaction that applies to distributed systems as well, where many 
machines or processors interact through a network. Communication between processes is 
necessary for concurrent programming to be useful; thus we wish to construct and 
examine a definition of a transaction which can be used to reason about such inter-process 
communication. 



II. B;u hi; round 

Actors and events are the basic concepts of the actor theory. Actors 
communicate with one another by sending messengers to each other. Each messenger 
contains information which the receiving or "target" actor then acts upon. An actor may 
create another actor, in fact, most messengers (which are also actors) are created just 
before being sent off to another actor. An event occurs when a messenger arrives at its 
target actor. Often we use the notation: 



is: [T <™ M] 
to mean that target (Is) ~ T and messenger! D = ML 
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Actors which a given actor directly knows about arc called its "acquaintances", 
lor .^n event E, the "participants" of E are the target(E), the messenger(E), and the 
acquaintances of target(E) and of messongcr(E). An actor maintains a vector of 
acquaintances, which may or may not change over time, It may gain new acquaintances (or 
Id get otr! ones! through the acquaintances of a message sent to it. An example of an 
actor whoso acquaintances change over time is a "cell". It has one acquaintance, and can 
receive either a "contents?" request, in which case it replies with its acquaintance, or a 
update request, in which case it forgets its old acquaintance and remembers the new one 
given <o it by the update request, The behavior of other actors whose vectors of 
acquaintances may change with time are given in [Hewitt and Attardi, 1978]. 

The significance of an event causing an actor to change its vector of 
acquaintances is that such actors therefore are "order-dependent". That is, the order in 
which they receive messages can effect the replies they send to these messages. Such 
actors are ''serialised" so that they can assign an "arrival ordering" to their messengers. If 
the message of event E l arrives at a serialized actor S before the message of event E 2 , 
^^■^ then we write; 

E} -arr$ -> E 2 

Another type of ordering is the "activation ordering". If as a result of 
receiving a messenger M in an event E? the target actor sends another messenger M 2 to 
an actor A, then \\ 2 is s^aicl to activate E 3 whore E 3 is the arrival of M 2 at A. We write: 

E ? ~oct'~> E3 

The transitive closure of these two kinds of orderings is called the "combined 
ordering", and according to the above two examples we could write: 
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■II. Transactions 

II. i. Request and Reply Fvents 

In order to study transactions we must have a formal definition of a request and 
a reply. A request is simply the messenger in any event of the form: 

[ ... o~ [request: ...,reply-to: c] ] 
where c is a continuation. The definition of reply as given in [Hewitt and Baker, 1977] is: 

If an event F is of the form 

[ ... <*■"* [request: ...,reply-to: c] ] 
then any event t? of the form 

[c o~ [reply: ...] ] 
such that E wrW>E' will he said to he a reply to E. 

i\Ve will frequently refer to an event whose messenger is a request or a reply as a 
request or reply event, respectively. We use the notation "reply(RQ)" to mean the event 
whose mewenper is (he reply of the request event RQ. This paper assumes that at most 
one reply exisis for each request.) But this definition of a reply is too strict. Consider 
the «:," in winch a request is sent to a serialized actor X in event RQ. Suppose that 
hefote Koi.rlii.R a reply, X demands that it receive "permission" to do so. Permission is 
craned in the'"' form of the receipt of a clock pulse, which may arrive before or after the 
receipt of the request event. Cdlinp, the event in which the clock pulse arrives at X 
event F, we have.E: [X ''~~ pulse). The pulse allows the reply to the first message to be 
sent .uul it arrives at (he continuation in event RP, such that RP: [C <~~ [reply: ...] I 



RQ: [X <'-'" [request: M, reply-to: C] ] 
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[X o~ pulse] .7,:,'- > RP: [C <~~ [reply: ...] ] 
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Wf j sec that RQ an >: >£-.ac( >RP. There is no activation ordering between RQ and RP* 
but RP should Mill constitute a reply to RQ. We therefore propose that the definition of 
reply he weakened to: 

If an event E is of the form 

[ ... <^~ [request; ,..,reply-to: c]] 
then any event F/ of the form 

[c 0~ [reply: ...]] 
such thai £—•->£' will be said to be a reply to E, 

Pv dunging the requirement of an activation ordering between the request and its 
associated reply to a combined ordering we allow events which are ordered by arrival 
ordering to enter the path between request and reply. 



II. ii. Redefining Transactions 

Hewitt and Baker's definition of a transaction (given this paper's assumption that 
at most one reply exists for each request) is; 

transaction(RQ) * RQ--> H — >reply(RQ) 

where RQ is an event whose messenger is a request. 

Intuitively, a transaction is an attempt to characterize the notion of a process in 
conventional programming languages, since only those events which contribute towards the 
request's reply are included in the transaction. 

Tor example, consider art event RQj in which a message M arrives at a serialized 
actor X with continuation C, that is, RQj*. [X o^ [request: M, reply-to: C] ]. Let X 
then receive a second message (VV, such thu RQ 2 : [X o~ [request: N\\ reply-to: C '] ]. 
X replies to M' first by sending R' to the continuation C\ It then replies to M. The 
following events and orderings are relevant. 
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RQ,: [X <~~ [request: M, reply- to: C] ] 
RQ ? : [X ''~~ [request: M', reply-to: C] ] 
RQi -<»r x ->RQ 2 

Riy [C* <~~ R'] 
RP,: [C O"' R] 
RQ, - fll 7-> RP, 
RQo -(7tr-> RP 2 

RQ,: [X <~~ [request: M, reply-to: C] ] -act-> RP,: [C <~~ R] 



RQ ? : [X. o~ [request: M\ reply-to: C] -acf-> RP 2 : [C <~~ R ? ] 



Now, transactionl'RQ,) = {RQ„ RP,}, and transaclion(RQ 2 ) s {RQ21 RP 2)« Although 
RQ r — >RQ ? , RQ ? is not an element of iransaction(RQ,), because it is not true that 
RQ. >RP S Q 

However, as originally pointed out by Craig Schaffert, we note that a 
discrepancy can arise with this definition. Consider the case in ILL above in which a clock 
pulse was used to activate the reply to a request. According to Hewitt and Baker's 
definition of a transaction, transaction(RQ) = {RQ, E, RP}. But if the clock pulse arrives at 
X before RQ, we have the following situation: 

E -<7/t x -> RQ ~(7tf-> RP 

Now transaction(RQ) = {RQ, RP}- 'Phis raises several questions concerning just what 
should ho included in a transaction. Should I be included in the transaction in either case? 
Should it not? Should the whole computation fail to be recognized as a transaction? 
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In keeping with our intuitive discussion of transactions, it seems that we 
f -.houIclit't throw out. t ho whole computation, hut we must now decide whether E should he 
included or not, and in either case, its inclusion or exclusion should be consistent and not 
dependent on the arrival ordering of E. 

Carl Hewitt has proposed that those events which are not request events or 
reply events (where a replv is extended to include complaints), should not be allowed to 
be member:; of any transaction. This constraint is in keeping with our concept of a 
transaction as that "thing" winch models the classical notion of a process as a set of 
nested request events and events which reply (o those requests. 

Adding this constraint to our definition of a transaction we see that in order to 
determine whether If, should be included in transaction(RQ), we must know whether it 
const itut"s a request (vent or not (clearly it is not replying to X). If E is not a request 
event, then if will not he a member of transaction(RQ) regardless of' where it comes in the 
arrival ordering of X with respect to RQ, However, if E is a request event, it necessarily 
has an as r ocnted reply event. We will assume then thai there is an event R such that R = 
replv (E). We can now put some constraint on R in order to include or exclude E (and R) 
from transact ion! RQ). Following our intuitions (this is a definition, after all), we add the 
constraint that if E is a request, in order for E to be an element of transaction(RQ), 
Is ->reply(RQ). More formally, we now have: 

lor some request or reply event E', E' < transaction(RQ) iff 

WQ ~->F.', E' >reply(RQ), and if E' is a request event, 

then reply(E')— >reply(RQ). 

What this me-ms is that if a request event is to be part of a transaction its associated 
replv event should be also. For the clock pulse example then, transaction(RQ) ~ {RQ, RP} 
where If is not included at all, since E is neither a request nor a reply event. Note that 
since we have added constraints to the definition of transaction but not eliminated any,- 
tint no event winch was not part of a given transaction will now be defined to be. We 
have only eliminated certain "ad hoc" events from some transactions. We will examine 
later how this effects some of the results presented in [Hewitt and Baker, 197S]. 
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II. tii. Properly Nested Transactions 

We would now like to prove some properties of these transactions. In 
particular, it would be nice io be able to say thai transactions are "properly nested". That 
IS that two transactions are either disjoint, or that one is a subset of the other, 

t lufot (unaU>lv, a counter-example follows. 

Consider (he following event network and its associated orderings (Where the 
RQ's are request events, the RP's are reply events, and the E's are neither. RP's 
correspond to the RQ with the same subscript): 



RQi -«ct~> RQ 2 
RQ ? ~act-> RQ 3 , RQ4 
RQ 3 -act~> RP 3 
RQ t1 -act- > RP 4 

rp 3 -act-> 1;,, \: 2 



\\\\ ~acl~> E 3 , E4 
E, -arr x ->'E 3 
l ? -arrx -> E4 
E 3 -act-> RPj 
E« -act-> RP 2 



f ac(~> Ej 



RQi -«<:f~> RO9 

V 



i 



(7(7- ■> RQ 3 -flrt-> RP 3 (7t7-> E 3 ~act~> RPj 



RQ„ -<ra'-> RI% 



x 



(7rr K 
V(7-> Eq ~<7(7~> RP 2 



'We wish to determine which events are members of transaction(RQj) and which 
are members of < ransaction(RQ ? ). Transactior^RQj) consists of RQ, (obviously), but not 
KO ; >, ■<■■ in.ee RP ? « reply(RQo) has no ordering with respect to RP, = repiy(RQ,). RQ 3 and. 
\\Qq are both elements, since they are ordered with respect to RQ j and RP,, and their 
respective replies precede RP,. Then their replies RP 3 and K? A are also members. E, 
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though l\ 3 iiv not members of IransactiontRQ j) since they are neither request events nor 
teplv events, i'nnllv, \\\\ is a member of transactionlRQj), Therefore, transactionfRQ j) ~ 
iKQi, RQK KQ„, RIS, RP„, RP,}. Similarly, transaction(RQ ? ) - (RQ ?) RQ 3) RQ , RP 3 , RP 4 , 

RP,K 

The interaction of I rans^ciionfRQ i) with transaction(RQ 2 ) consists of four 
eveiits, \\\Q :]1 \{Q ih RP 3 , RP/jK and although this set is not a transaction itself, it consists 
of the union of two transactions, (It is possible to show that the intersection of two 
(ran- .actions is always equal to the union of some number of other transactions.) However, 
transac.tionSRQj) is clearly not contained in transaction(RQ 2 ), nor is transaction(RQ 2 ) 
cont lined in transaclion(RQj). 

Well, all is not lost, for we can prove at least a slightly weaker property, 
though one which is still quite useful. Though we can not show that given any two 
transactions with at least one event in common, one transaction must be contained in the 
othor, we can show that if a request event RQ is an element of transactionfRQ 1 ), then 
transaciion(RQ) ■ c iransaciion(RQ'). This is called the Law of Containment for 
Twin tactions. 

Assume that Is < transaction(RQ). To show that E ( transaction(RQ'), we must 
show 

Coal 1: RQ 1 — >E — >ro P ly(RQ') 

and if \i is i request event, that 

Coal 2: roply(E) — >ropIy(RQ f ). 

Since Is * transaction(RQ) we hwe: 

RQ.--->E--->rcply(RQ) 
and since RQ •' 1 1 ansaciionlRQ'): 

RQ'-- >RQ— >replv(RQ)-->roply(RQ'). 
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i hen x 

RQ' ->RQ ■— >E >roply(RQ)— >reply(KQ') 

Thus RQ' TT-- >replv( RQ'), which proves Coal i. 

Assume Is is a request event in order lo prove Coal 2: 

rcply(E)— >rep!y(RQ'). 

Since I. ■ trans.«ction(RQ) I hen 

repIy(E) ■ — >reply(RQ), 

.h'hI since RQ < transact ion(RQ'), and RQ is a request event, 
we hiiovs 

rcpiy(RQ) >rcply(RQ'). 

Thus ?'(-plv(l ; :)-~>roplv(KQ'). [Done] 

ill. Continuous I unctions is 

III i. Continu uion Ordering 

lofore wo f<o on, let's briefly characterize (hose events which we have 
oliminUecl from transactions. First of all, we have eliminated from transactions all those 
events 1 which are neither request nor reply events, Secondly, we have eliminated all those 
request events whose associated reply events do not also participate in the transaction, 

Hewitt tnd Baker have defined a third ordering on events called the 
continuation ordering. In this ordering, Fj -cont~> E 2 if D there is some transaction c/. 
such that Lj and F ? are both members of </, and 2) Ej —-> E 2 . Our redefinition of 
transaction affects this ordering to the extent that now if Ej ~cont~> E 2 ,we may 
-automatically conclude that F.j arid E 2 are either request or reply events since no other 
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type ol event uny he an element, of some transaction, and furthermore, given the ordering 
KQ] -corj-y KQ ? , we can conclude rep!y(RQ 2 ) -co»r-> reply(RQ { ). It is also the case that 
some continuation ordering lh;it once held between two events may no longer hold, since 
some events have heen eliminated from transactions. But no additional continuation 
ordering will hold due to the redefinition of transaction. 



111. ii. Fork and Join Behavior 

The fork and join behavior discussed in Section IX of [Hewitt and Baker, 1975] 
holds up beautifully under the new definition of transaction, as long as no join occurs 
without a previous fork first providing the components of the join. This prerequisite is 
easy to fulfill, however, since the classic notion of a process implies that that is always 
the rase. 



11L iii. Procedures and Mathematical Functions 

The definition of a procedure as given in [Hewitt and Baker, 1975] requires that 
1) all events involved in the procedure are either request or reply events, 2) there is at 
most one reply event for each request event, and 3) the transactions are properly nested. 
Tint is, for any two transactions in the procedure, either one is a proper subset of the 
other, or they are disjoint. 

Wh wish to show that any transaction which was a procedure under the old 
definition is still a procedure under the new definition. That is, we wish to show that any 
event which was eliminated from a transaction by the new definition of transaction would 
not h'U'e passed as an event which could be part of a procedure anyway. If we can do this, 
then tlu* results given in [Hewitt and Baker, 1975] for continuous functional will still hold, 
since they are Insed on actors which behave like mathematical functions, and mathematical 
functions depend on procedures for their definition. 
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We have already characterized the events which were eliminated from 
trans-actions. Those which are neither request nor reply events can not be part of a 
procedure under the .first restriction. Those request events whose corresponding reply 
events were not part of the transaction cannot he part of a procedure either, under the 
following .reasoning. Assume the existence of a request event RQ which is a member of 
trans-actionUv), hut whose reply KI' is not. Then RQ is also a member of transaction(RQ), 
as is its replv, RP. Then transaction(R) and transaction(RQ) are not disjoint in that they 
both contain RQ, but there is no containment since RP is not an element of transaction(R) 
(therefore transar.tion(RQ) is not contained in transaction(R)), and since R — >RQ ? R 
cannot be an. element of iransactionfRQ) (therefore transaction(R) is not contained in 
transacuonlRQ'i), Thus, no such transaction would pass as a procedure anyway. 

Thus, even with the new improved definition of transaction, we can still show 
thai if an actor behaves like a mathematical function, then it is the limit of a continuous 
functional in the sense of Scott. It remains to be seen if analagous results can be shown 
to hold true for order-dependent actors. 



IV. Conclusions 

We have uncovered two "buRs" in the [Hewitt and Baker, 197S] paper, one with 
the definition of "reply", and one with the definition of a "transaction". We proposed 
alternative definitions for both, and showed how these new definitions solved the 
discrepancies raised by the original definitions. Using the new definition of transaction, 
the LuiV of Containnwiit for Transactions was proved, and the definitions of a procedure 
and a mathematical function were shown to hold true, Because these definitions held, we 
wore able to maintain the result that if an actor behaves like a mathematical function, then 
st is the limit of a continuous functional in the sense of Scott. 



PAGE 13 



/""> 



/^. 



V. fum re* Work 

Wo have not yet discussed the uniqueness of replies, or indeed how multiple 
replies might effect the definition of a transaction. Although normally a request has only 
one reply, i( is conceivable that an actor might have a behavior that causes multiple replies 
to be sent in response to some request. 
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